Magnum One

home *** CD-ROM | disk | FTP | other *** search

/ Magnum One / Magnum One (Mid-American Digital) (Disc Manufacturing).iso / d19 / ov_msg.arc / OVPLUS.MSG < prev

Wrap

Text File | 1990-10-17 | 17.0 KB | 406 lines

Date: 10-08-90 (14:52) Number: 573 / 588 (Echo) To: DENNIS EDWARDS Refer#: NONE From: TIM FARLEY Read: 10-11-90 (19:55) Subj: Question about /D:ICA Status: PUBLIC MESSAGE Conf: OMNIVIEW (6) Read Type: GENERAL (+) Still having some intermittent lockups on our BBS. It's gotten very frustrating, because they leave no useful evidence behind, and typically occur only when the system has been left unattended. Some of these lockups feature some I/O redirection (console output redirected into a file that happened to be open) of the type I previously described. Others frequently revolve around an apparently "unhooked" comm port IRQ. Anyway, all that aside, my investigation lead me to believe that perhaps PCBoard 14.2 uses the "ICA" area of memory. Since I didn't have /D:ICA on my OV command line, this could be a problem. I'm still waiting to hear a definitive answer from CDC on this question, meanwhile I decided to investigate. However, I'm not the type to just blindly add a command line option and hope, so I decided to probe a little. I wrote a program that would continuously dump the ICA, and ran it in one partition, while I vigorously excercised the operating PCBoard node in the other partition. I saw no change from 16 bytes of 00's during the run. So then I manually altered a few of the bytes of the ICA, to see if they would show up in the dump in the other partition. They didn't! I found I was able to fill the two ICA's in the two opposite partitions with specific (unique) values, without interfering with one another. All this *without* the string "/D:ICA" on any of my command lines. Which leads to the question: if OV 4.13 is already preserving the ICA over task switches anyway, just what does "/D:ICA" do? --Tim Farley Date: 10-09-90 (19:17) Number: 574 / 588 (Echo) To: DENNIS EDWARDS Refer#: NONE From: TIM FARLEY Read: 10-11-90 (19:55) Subj: AMRS SETTINGS Status: PUBLIC MESSAGE Conf: OMNIVIEW (6) Read Type: GENERAL (+) Quick question: If I have the AMRS parameter set too low on my memory manager, will it affect OV's performance even if I am not allowing any of the tasks to swap? Date: 10-09-90 (19:21) Number: 575 / 588 (Echo) To: DENNIS EDWARDS Refer#: 569 From: TIM FARLEY Read: 10-11-90 (19:55) Subj: NEW OMNIVIEW VERSION! Status: PUBLIC MESSAGE Conf: OMNIVIEW (6) Read Type: GENERAL (+) >386-Mate: NEW! > Interrupt handlers can be swappable. I assume you are referring to interrupt handlers within OV while it is running, right, like comm programs that are operating inside an OV partition? >OMNIVIEW: > User written OMNIVIEW device drivers support. You can now get > configuration information when a new process is created > (passed with the USR_ALLOC signal in DS:DX as part of the > "DOS" device parameter string). I'll post more on this > later - it's implications are significant. I am very much interested in hearing more about this as soon as you get some time. --Tim Farley Date: 10-09-90 (19:24) Number: 576 / 588 (Echo) To: DENNIS EDWARDS Refer#: NONE From: TIM FARLEY Read: 10-11-90 (19:55) Subj: OMNIHIGH and XMS Status: PUBLIC MESSAGE Conf: OMNIVIEW (6) Read Type: GENERAL (+) I haven't gotten my 4.20 upgrade yet, (but it's supposed to be on the way), so this question may sound stupid. Has OMNIHIGH been made XMS-aware in 4.20? The reason I ask, is in 4.13, in order to use OMNIHIGH, you have to give 48K of RAM to the EMS manager to remap into somewhere other than the normal EMS page frame. Unfortunately, that's 48K of memory that *can't* be allocated to loading TSR's. That may sound silly, since obviously if I loaded TSR's in that memory, I wouldn't be able to load OMNIHIGH there, right? But it's not that easy---because of the vagaries of TSR loading, I have to have alot more memory available up high during the load process, than the TSR's actually need. SUPERPCK, for instance, in my configuration, uses about 58K while initializing, but only 16K when resident. So, I end up with an amount of RAM up above my TSR's that are loaded high, that is effectively wasted---I don't have any more TSR's to load there, but OMNIHIGH won't allocate it. Finally, Tim gets to the point: because of the way that 386-MaX works (and QEMM 5.x may or may not be the same way, I haven't checked), the memory that is used for loading TSR's HIGH *can* be shared with the XMS "Upper Memory Block" calls, and it in fact is. But memory allocated for EMS's use in a manner compatible with OMNIHIGH *cannot* be shared with TSR loading. Bottom line: If OMNIHIGH would use the XMS "Allocate UMB" call to allocate the high memory it needs (if and only if the EMS calls it makes now do in fact fail) it would be much more compatible with the "loadhi" functions of 386-Max at least, possibly also QEMM. Did that make any sense? --Tim Farley Date: 10-12-90 (12:13) Number: 577 / 588 (Echo) To: TIM FARLEY Refer#: 573 From: DENNIS EDWARDS Read: 10-12-90 (18:20) Subj: Question about /D:ICA Status: PUBLIC MESSAGE Conf: OMNIVIEW (6) Read Type: GENERAL (+) │Still having some intermittent lockups on our BBS. It's gotten │very frustrating, because they leave no useful evidence behind, │and typically occur only when the system has been left │unattended. Some of these lockups feature some I/O redirection │(console output redirected into a file that happened to be open) │of the type I previously described. Others frequently revolve │around an apparently "unhooked" comm port IRQ. Sorry. The former may be a result of a feature of DOS that can be avoided when you get 4.20. I don't know what to say about "unhooked" IRQ's. Do you mean that the PIC/UART is turned off or that the vector has been changed? │Which leads to the question: if OV 4.13 is already preserving │the ICA over task switches anyway, just what does "/D:ICA" do? The standard OMNIVIEW devices can have a status, which they tell OMNIVIEW about after they initialize themselves, which requires them to be allocated for each user process. Because of the unruliness of certain BASICs we were forced to assign this status to the ICA device. The ICA device also saves and restores a variety of data in segment 50h which is outside of the ICA proper. Other devices not documented as being mandatory for each process include DOS and OBJQ. So, BASICly, /D:ICA just takes up space in your .BAT files. --- ■ EZ 1.30 ■ Date: 10-12-90 (12:13) Number: 578 / 588 (Echo) To: TIM FARLEY Refer#: 574 From: DENNIS EDWARDS Read: 10-12-90 (18:20) Subj: AMRS SETTINGS Status: PUBLIC MESSAGE Conf: OMNIVIEW (6) Read Type: GENERAL (+) │Quick question: If I have the AMRS parameter set too low on my memory │manager, will it affect OV's performance even if I am not allowing any │of the tasks to swap? AMRS is a quantity that effects a couple of things. IF you don't have at eight of them then we figure you're not really running on LIM 4.0 hardware which has various implications. If you have 8 or more AMRS but (AMRS-1) < tasks then you have a problem since there will not be hardware storage for the EMS context state. That will slow things down. On a '386 or later such things are magical and virtual but their implications are the same as if "real" hardware were involved. Assuming this is a '386 box, why would you not want to "swap" your processes out to EMS? --- ■ EZ 1.30 ■ Date: 10-12-90 (12:13) Number: 579 / 588 (Echo) To: TIM FARLEY Refer#: 575 From: DENNIS EDWARDS Read: 10-12-90 (18:20) Subj: NEW OMNIVIEW VERSION! Status: PUBLIC MESSAGE Conf: OMNIVIEW (6) Read Type: GENERAL (+) │> Interrupt handlers can be swappable. │ │I assume you are referring to interrupt handlers within OV while it is │running, right, like comm programs that are operating inside an OV │partition? Yes. │> User written OMNIVIEW device drivers support. You can now get... │I am very much interested in hearing more about this as soon as you get │some time. Please see the description of EXPECT in my General Apology. I'm posting the source code to this utility along with the latest revision of the .ASM API on Poverty Rock as I deliver these messages. In addition to being a "user written OMNIVIEW device driver" it also shows you how to do more typical OAPI stuff in the framework of a conventional program since it is both a TSR and a transient utility. That file also includes a front end filter for use in speeding up searches that you may find interesting. --- ■ EZ 1.30 ■ Date: 10-12-90 (12:13) Number: 580 / 588 (Echo) To: TIM FARLEY Refer#: 576 From: DENNIS EDWARDS Read: 10-12-90 (18:20) Subj: OMNIHIGH and XMS Status: PUBLIC MESSAGE Conf: OMNIVIEW (6) Read Type: GENERAL (+) │I haven't gotten my 4.20 upgrade yet, (but it's supposed to be on the │way), so this question may sound stupid. │ │Has OMNIHIGH been made XMS-aware in 4.20? OMNIHIGH itself always has been able to use XMS. That is why it says: "Could not allocate EMS or upper memory blocks." when it fails to find high non-DOS memory. If you can map XMS into the spot where OMNIHIGH loads high now, and if that will give more room for TSR load, and if you still end up with 48K left over after loading stuff then by all means: Do It. But, and it is a BIG BUT, OMNIVIEW does not and cannot use the HMA, which is a different sort of critter. OMNIVIEW is almost entirely a bunch of interrupt handlers and they are (by definition) restricted from loading there. There probably is some stuff that we could have stuck up there. But it wasn't part of the initial design of the kernal and the device dispatcher, etc. and so it will take a significant re-write of OMNIVIEW to accomplish that. Also consider that, DOS 5.0 is rumored to use XMS for lots of stuff and that could free up a lot of room for everybody else. 386^Max has the Flex Frame option that allows you to temporarily encroach on the standard EMS Page Frame in order to initialize your TSRs that are loaded into high memory. 386-Mate doesn't offer that capability. --- ■ EZ 1.30 ■ Date: 10-12-90 (12:13) Number: 581 / 588 (Echo) To: ALL Refer#: NONE From: DENNIS EDWARDS Read: (N/A) Subj: a General Apology (news) Status: PUBLIC MESSAGE Conf: OMNIVIEW (6) Read Type: GENERAL (+) I wish to offer our apoligies to all who are waiting on OV. The manuals should at last be back from the printers and so shiny new packages should be shipping next week. Really. As an act of atonement, I have made use of the time to write some new utilities that I think you will like. I have also redone the .ASM OAPI and that is just now posted on Poverty Rock along with the 2500+ lines of commented source code to EXPECT. In additition to showing you how a real program can make use of both the OAPI and OXSI interfaces to OMNIVIEW, it includes a filter that can be applied to a search string to speed up searches of English text. This filter could be modified to work with other types of data that are well understood. And what is EXPECT, you ask earnestly? It is a program that watches the screen of another OMNIVIEW partition and waits for a specific string to appear. This is similar to the PROCOMM macro language function of the same name except EXPECT works for data on the screen of any partition. Some UNIX systems support a similar function. You use it to synchronize a control script with events in the partition being controlled. It is both a TSR (an user writtern OMNIVIEW (OXSI) device driver) and a transient program (that is quite OMNIVIEW (OAPI) specific). And that's not all, you also get a utility that (re)names a process from the command line. Another will search for a named process and set ERRORLEVEL to its console number if it exists. Yet another will keep the BIOS from dumping the screen of a background partition when you press the <Prt Scrn> key. And another will block a partition's access to the mouse so that they will be able to run in the background. Again, I apologise for the delay and thank you for your patience. Happy computing. --- ■ EZ 1.30 ■ Date: 10-12-90 (12:13) Number: 583 / 588 (Echo) To: ALL Refer#: NONE From: DENNIS EDWARDS Read: (N/A) Subj: OBJections to objects Status: PUBLIC MESSAGE Conf: OMNIVIEW (6) Read Type: GENERAL (+) The OAPI is being revised, redocumented, broken up into language specific components and being made available by MODEM. The first step in this process has taken place and exists in the form of Rev. 4.20 of the .ASM OAPI file. This includes details of the OMNIVIEW eXternal System Interface (OXSI) used to construct OMNIVIEW device drivers. A real working progam is included which utilizes both interfaces and has some interesting features. We would like to give you what you want if we can. I am intersted in feedback on the .ASM OAPI contents. I am particularly interested in knowing the interest level in the construction of an OOP interface. Any thoughts you have on the composition of the object and what languages you would like to see them in first (it will be .ASM by default) will be seriously considered. Please leave any thoughts you may have here. Perhaps some helpful dialogue will develop. If you prefer send text/code/data via US Mail to the address in the OV manual. Put my name on it somewhere. Thanks in advance and good coding. --- ■ EZ 1.30 ■ Date: 10-13-90 (14:35) Number: 586 / 588 (Echo) To: DENNIS EDWARDS Refer#: 578 From: TIM FARLEY Read: NO Subj: AMRS SETTINGS Status: PUBLIC MESSAGE Conf: OMNIVIEW (6) Read Type: GENERAL (+) DE>Assuming this is a '386 box, why would you not want to "swap" your DE>processes out to EMS? No good reason. Just a carry over from the days when we were running a 286 box. I've been reluctant to add the /S parameter because of the lockups lately, but actually I am also anxious to add it because obviously it will make the system much more flexible (I can fire up some more tasks and such). --Tim Farley Date: 10-13-90 (14:35) Number: 587 / 588 (Echo) To: DENNIS EDWARDS Refer#: 580 From: TIM FARLEY Read: NO Subj: OMNIHIGH and XMS Status: PUBLIC MESSAGE Conf: OMNIVIEW (6) Read Type: GENERAL (+) TF>Has OMNIHIGH been made XMS-aware in 4.20? DE>OMNIHIGH itself always has been able to use XMS. That is why it says: DE> DE> "Could not allocate EMS or upper memory blocks." DE> DE>when it fails to find high non-DOS memory. If you can map XMS into the DE>spot where OMNIHIGH loads high now, and if that will give more room for DE>TSR load, and if you still end up with 48K left over after loading stuff DE>then by all means: Do It. Hmmm...well, for some reason I cannot get this to work on my rig. I have 60K free continguously free in my UMB area after TSR load, and OMNIHIGH will NOT load. I just shelled out and tried it---I have a 60352 byte UMB available, verified by running a very simple UMB-aware program I have written. (And yes, it does release them when done--I can run it many times with the same result). But OMNIHIGH 4.13, when run, issues the above referenced error. DE>But, and it is a BIG BUT, OMNIVIEW does not and cannot use the HMA, which DE>is a different sort of critter. Yes, I very much understand that---we've discussed it here before. DE> Also consider that, DOS 5.0 is rumored to use XMS for DE>lots of stuff and that could free up a lot of room for everybody else. Yes, I think loading up there wouldn't be worth the trouble right now, especially with the rewrite it would take. It might be nice if OV could put some if its buffers up there without much trouble. DE>386^Max has the Flex Frame option that allows you to temporarily encroach DE>on the standard EMS Page Frame in order to initialize your TSRs that are DE>loaded into high memory. 386-Mate doesn't offer that capability. FlexFrame sure is a cool option, and it's really quite simple to use. The principle behind it (disable EMS, temporarily map some ram into the page frame, then undo after the TSR goes TSR) is really so conceptually simple I'm surprised nobody else has done it before this. Or maybe I'm just naive and it's really alot more complex than that? <grin> --Tim Farley (H)elp, (150-588), Message Read Command?